Details of bundle changes

Generated by 🚫 dangerJS against 216fac6

I have noticed a change of behavior after click the "Click" button on iOS Safari 14 and Android Chrome 86. The tooltip is no longer rendered with the "touch" styles.

https://next.material-ui.com/components/tooltips/#triggers OK ✅

https://deploy-preview-23088--material-ui.netlify.app/components/tooltips/#triggers KO ❌

It sounds like we need to keep the logic but add a regression test case.

Thanks for the report 👍 That's definitely indicative of an actual issue but can we talk about <Tooltip disableFocusListener disableHoverListener disableTouchListener title="Add" />? What would be the point of only showing the tooltip after you clicked? Especially because that behavior needs another component (ClickAwayListener) to work.

Which goes right into the discussion of classes.tooltip:

Styles applied to the tooltip (label wrapper) element if the tooltip is opened by touch.

It's not actually opened by touch but click in the problematic demo so it's technically correct to not apply the styles. If you want to argue that this is concerned about "user-touch" then it doesn't make sense to apply these styles if disableTouchListener is set. Seems pretty confusing to me to use "touch" in both names but mean something different (user-touch vs touch-event).

Styles applied to the tooltip (label wrapper) element if the tooltip is opened by touch.

We could improve the description of this prop and the behavior. I see two concerns.

First, on a touch interaction, you want to compensate for the size of the finger that triggered it. Otherwise, you might not see the message, hidden behind your finger. It's the same concern with a mouse, only that it cover a smaller area (unless maginifed).
Second, on a smaller screen, we probably want to increase the size of the tooltip to improve readability.

So far, we have mixed the too and used the touch start event to trigger the style. I'm not aware of any significance issue with such approximation.

I'm not sure what's the right thing to do here. At least, I hope that the previous comment explain the objective with the style.

I can't remember why we have a disableTouchListener prop, I could only find #20245

At least, I hope that the previous comment explain the objective with the style.

I definitely understand why we have separate styles for touch devices. I think they should be applied at another point though. Why make the tooltip bigger when we register touch input but not the button that triggers it? Intuitively I rather add @media (pointer: coarse) { .Mui-Tooltip { font-size: 1.2rem } }

My point is more that if I want to disable the touch listener I would also expect any special handling of touch events to be ignored.

@media (pointer: coarse)

To be careful, it might not work on Samsung Galaxy phones, to be tested. We discovered that in #1500. In mui/material-ui-pickers#1653, I have found that @media (pointer: fine) was reliable.

My point is more that if I want to disable the touch listener I would also expect any special handling of touch events to be ignored.

Agree, for controlling the open state. I think that It would be surprising if the disableTouchListener prop impacts the style of the tooltip.

I think that It would be surprising if the disableTouchListener prop impacts the style of the tooltip.

I want to do some more interaction research but I'm fairly certain we can just drop this prop. enterTouchDelay={Number.POSITIVE_INFINITY} does the same. As it stands right now I'd rather make this behavior stand out in the implementation. disableTouchListener looks harmless when it is in fact not harmless at all.

Will revisit later.